home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 25
/
Cream of the Crop 25.iso
/
comm
/
rshdn211.zip
/
WRSHDNT.TXT
< prev
next >
Wrap
Text File
|
1996-12-04
|
80KB
|
1,887 lines
DENICOMP SYSTEMS Winsock RSHD/NT
----------------------------------------------------------------------
Copyright 1995 Denicomp Systems
All Rights Reserved
INTRODUCTION
Winsock RSHD/NT (Remote Shell Daemon) is a service for Windows NT
that accepts requests for command execution and file transfers
from other hosts on the network via TCP/IP and executes them on
the PC running Winsock RSHD/NT. It runs under Microsoft Windows
NT 3.5 or higher.
Winsock RSHD/NT is similar to the Unix server of the same name,
but provides some special functionality for the Windows
environment, such as:
- Ability to send keystrokes to the command running under Windows NT
- Support for the rcp command to allow copying to and from the PC
- Security mechanism to allow/deny access for hosts and users
- Capture of standard output/standard error output of NT Console and
MS-DOS programs
Command requests can come from hosts running other operating
systems such as Unix or from other PC's running Windows NT or
Windows 3.1 using the standard rsh utility that comes with your
TCP/IP package or Winsock RSH, also available from Denicomp
Systems.
Files can be copied to the PC or from the PC running Winsock
RSHD/NT using the standard TCP/IP rcp command. This includes the
rcp command available with Unix or Windows NT or a PC-based rcp
command such as Winsock RCP, also available from Denicomp Systems.
REQUIREMENTS
Winsock RSHD/NT requires a Intel x86-based PC running Windows NT
3.5 or higher and a network.
Winsock RSHD/NT does not run under Windows 95. There is a version
specifically written for Windows 95 called Winsock RSHD/95.
Contact Denicomp Systems for more information.
WINSOCK RSHD/NT INSTALLATION
To install Winsock RSHD/NT, insert the Winsock RSHD/NT diskette
into your diskette drive. Then, from the Windows NT Program
Manager menu, select File, then Run. Then type the name of your
diskette drive followed by "SETUP". For example, if the diskette
is in the A: drive, type "A:SETUP". Then press the Enter key.
(This can also be done from a Command Prompt if you prefer).
The Winsock RSHD/NT Installation window will then appear. Verify
that the drive letter shown in the Source field is correct. If it
is not, specify the proper drive.
Specify the directory in which you would like Winsock RSHD/NT to
be installed in the Destination field. This will default to the
\WRSHDNT directory on the drive where Windows NT is installed.
You may change it if you wish.
If you do not want Winsock RSHD/NT to be installed as a Windows NT
Service, uncheck the Install as Service option and it will not be
added to the list of Windows NT Services. Winsock RSHD/NT can be
run as a program instead of a service if you wish (explained
later).
Press the Install button to begin the installation. Press Cancel
if you wish to exit.
Files will be copied from the diskette onto your hard drive. When
all files have been copied, the installation will ask you whether
or not you want Windows NT to start the Winsock RSHD/NT service
each time Windows NT starts. Click Yes to start it automatically
each time Windows NT starts or No if you want to start it
manually.
The Winsock RSHD/NT service will then be installed in Windows NT's
list of services and it will be started.
See the section on Winsock RSHD/NT Utilities for instructions on
how to manually start and stop the Winsock RSHD/NT service.
REMOVING WINSOCK RSHD/NT
To remove Winsock RSHD/NT, you must first stop the Winsock RSHD/NT
service, then remove the service from Windows NT's list of
services. From the Windows NT Program Manager menu, choose File,
then Run. Enter the directory in which you installed Winsock
RSHD/NT followed by "wrshdctl". For example,
"c:\wrshdnt\wrshdctl". Press Enter.
From the Winsock RSHD/NT Control menu, first select "Stop the
Winsock RSHD/NT Service". Then select "Remove the Winsock RSHD/NT
Service".
Note: You may also use the Windows NT Control Panel "Services"
icon to do this.
You can then delete the Winsock RSHD/NT directory. You should
also delete the files WRSHDNT.CPL and WRSHDNT.HLP in the Windows System
directory (\WINNT35\SYSTEM32 for example). This is the Control Panel
applet for Winsock RSHD/NT and its help file.
RUNNING WINSOCK RSHD/NT AS A PROGRAM
You can optionally run Winsock RSHD/NT as a Windows NT program
instead of a service. This requires that somone log in to Windows
NT so that Winsock RSHD/NT starts.
To start Winsock RSHD/NT as a program, execute the following
command:
wrshdnt /s
If you are executing this command from the Windows NT Command
Prompt, you should use the command:
start wrshdnt /s
If you do not use the start command, you will not have access to
that Command Prompt window until Winsock RSHD/NT is stopped. Be
sure that you do not already have Winsock RSHD/NT running as a
service.
When Winsock RSHD/NT is started, it will display a window where
messages about the status of Winsock RSHD/NT will display. The
number and type of messages that display depends on the Message
Level option in the Winsock RSHD/NT Configuration.
To stop Winsock RSHD/NT, simply close the window.
Important Note: The ability to send keystrokes via the rsh
command through Winsock RSHD/NT does not work when it is running
as a program.
WINSOCK RSHD/NT CONFIGURATION
Winsock RSHD/NT will work properly using its default
configuration. You only need to configure Winsock RSHD/NT if you
wish to change any of the available options, enable security, or
use the logging capabilities. By default, no security is enforced
and no logging is done
You configure Winsock RSHD/NT by using the Windows NT Control
Panel. In the Control Panel, you should see an icon labeled RSHD.
Double-clock on that icon to configure Winsock RSHD/NT.
Important Note: After changing a Winsock RSHD/NT Configuration
option, you do not need to stop and restart Winsock RSHD/NT. It
will recognize the change, unless you disable the monitoring of
the registry (see below).
SECURITY AND LOGS
Security File: (Default: None)
Specify the full path name of the Security File used by
Winsock RSHD/NT to enforce security (allow and deny users and
hosts). The format of this file is explained in more detail
later. If you do not specify a Security File, all users and
hosts will be granted access to execute commands and transfer
files to and from your PC, unless you enable the option that
requires remote user names to exist as Windows NT users (see
below).
If you do specify a Security File and it does not exist, no
users or hosts will be granted access.
If you do not wish to enforce any security, do not specify a
filename.
Must Remote Users be Valid Users on this System? (Default: Unchecked)
If this option is unchecked, user login names sent to Winsock
RSHD/NT by rcp and rsh do not need to be valid users on this
system. Security is enforced soley through the Security
File.
If this option is checked, user login names from rcp and rsh
must be valid users on the this system. If the user is not
valid, access will be denied. This is the standard behavior
of a rshd daemon. However, if the rcp and rsh commands are
being executed from another operating system such as Unix,
the user login names may not be the same between systems. If
user logins are the same, you can then enable this option for
security. If they are different, you should not enable this option.
Message Log: (Default: None)
Specify the full path name of a file where any messages from
Winsock RSHD/NT should be stored. The message file is
optional. You should only enable the message log when you
are trying to find the source of a problem, since the message
log can become quite large on an active system.
This option is used in conjunction with the Message Level
option. If Message Level is set to a value greater than zero
(0), Winsock RSHD/NT will output messages that provide
information about its operation. These messages are mostly
useful for problem determination.
The message file created is a text file that you can examine
at any time using utilities such as TYPE or MORE, or editors
such as Notepad. You can clear the message log at any time
by simply deleting it.
Message Level: (Default: 0)
Specifies the level of detail of the messages stored in the
file specified in the Message Log option. The default level
is 0, which will not write any messages to the message log
file. Levels 1 through 4 will product increasing amounts of
detail (level 1 provides the least detail, level 4 provides
the most).
Request Log: (Default: None)
This option allows you to log all requests (commands to be
executed) in a file you specify. Each time someone attempts
to execute a command through Winsock RSHD/NT, the date and
time, the user name, the host name, and the command will be
written to this file.
Deny Log: (Default: None)
This option allows you to log all permission violations in a
file you specify. Each time someone is denied permission to
execute a command through Winsock RSHD/NT, the date and time,
the user name, the host name, and the command will be written
to this file.
Error Log: (Default: None)
This option allows you to log all command execution errors in
a file you specify. Each time someone receives an error
trying to execute a command through Winsock
RSHD/NT, the date and time, the user name, the host name, the
command, and error message will be written to this file.
These are errors that occur after the user has been
granted permission to execute the command. For example, an
error would be logged if a program was to be run that did not
exist.
NOTE: Each of the log files may refer to the same file name if you
wish. They will not overwrite each other. Each message is
appended to the end of the file. You should be sure to
periodically delete the log file(s) because they can get large
over time on an active system.
RSH OPTIONS
Reject All Incoming RSH Commands? (Default: Unchecked)
If you check this option, all incoming rsh commands will be rejected,
effectively disabling the rsh serving capability of RSHD/NT. This is
useful if you only want to use RSHD/NT as an rcp server.
If a remote user attempts to issue an rsh command to this system, an
error will be returned to the remote user stating that rsh has been
disabled.
Attempt Redirection on Every Command: (Default: Unchecked)
When you execute a command through Winsock RSHD/NT, it
assumes that the command is a Windows program (not a Console
or MS-DOS program) and that there is no redirection of
standard output/standard error back to the remote system,
unless you use the special "<[CON]>", "<[CON2]>", "<[DOS]>",
or "<[DOS2]>" indicators in the rsh command. (This is
explained in more detail later.)
If you mostly execute Windows NT Console programs and/or MS-
DOS programs via rsh through Winsock RSHD/NT, you can check
this option and Winsock RSHD/NT will assume that each command
is a Console/MS-DOS program and attempt to send its standard
output/standard error back to the remote system. It treats
every rsh request as if the "<[CON]>" option was specified.
You do not need to specify the "<[CON]>" indicator; it is assumed.
If you check this option, you still may execute Windows
programs via rsh and they will operate properly. However,
unless you specify the special "<[WIN]>" indicator for
Windows programs in the rsh command, there are a few
downsides: First, there will be slightly more overhead when
executing Windows programs because Winsock RSHD/NT will
attempt to capture the standard output/standard error. Also,
Winsock RSHD/NT will wait for the Windows program to complete
before closing the connection. Again, these downsides can be
overcome by specifying the "<[WIN]>" indicator.
Execute All Commands through Command Shell? (Default: Unchecked)
If you check this option, Winsock RSHD/NT will automatically prefix
every command you execute with the default command shell
(usually cmd /c).
This is useful if you commonly execute batch files (.BAT or .CMD) or
other command scripts for the shell you are using and you do not want
to have to specify the shell command in every rsh command.
The default shell command is used as the prefix. This command can be
specified in the Default Shell Command field; if no default shell
command is specified there, cmd /c is used.
For example, if this option is enabled and you execute the following
command from a remote system:
rsh ntsystem xyz.bat
RSHD/NT will execute the command as:
cmd /c xyz.bat
List of Commands to Allow (File): (Default: Blank)
This option allows you to specify the name of a file that contains a
list of commands that users are permitted to execute on this system
through rsh. This allows you to provide strict control over the
commands users can execute.
If no filename is specified here, all commands are permitted.
The file must be a plain text file, with each permitted command on a
line by itself. Commands in the file should not contain any spaces.
Comparison of commands is done only up to the first space or tab
character. When a user executes a command on this system through
rsh, RSHD/NT will extract the first part of the command, up to the
first space or tab character, and compare that to the lines in the
file specified. If it does not exist in the file, the rsh command
will be rejected.
Environment Variable File: (Default: Blank)
This allows you to specify the name or names of files that contain
environment variables that should be made available when commands
are executed by RSHD/NT through rsh.
Normally, the environment for commands executed through RSHD/NT comes
from the System Environment Variables specified in the System applet
in the Control Panel. Those variables are inherited from the Windows
NT Service Manager, so if the System Environment Variables are changed,
you must reboot the system for them to be propagated to RSHD/NT
(if you are running RSHD/NT as a service).
Alternatively, you can create a custom environment for RSHD/NT by
entering the environment variables and values in a plain text file.
Each line in the text file should have the format:
VARIABLE=VALUE
Each time a command is executed through RSHD/NT by rsh, a custom
environment is built from the file or files specified in this parameter,
based on the lines in those files.
You can specify a single filename or multiple filenames, with each
separated by semi-colons (;). Each file is read in sequence and
added to the System Environment Variables inherited by RSHD/NT to
create a new environment for the command to be executed. If a
variable name appears in multiple files, the last value read will
be used.
You may reference previously set environment variables as you do in
Windows NT batch files using %VAR%. For example:
PATH=%PATH%;C:\MYPROGS
The filenames should be full path names. There are three special
keywords that you can use in the filenames if you wish:
%ruser% - Substitute the login name of the remote user
%luser% - Substitute the login name of the local user
%rhost% - Substitute the host name of the remote host
The %ruser% substitutes the login name of the remote user. This will
be the login name the user used to log into the remote host from which
the rsh command is being issued, unless the -l option of the rsh
command was used to specify a different user; then that user will be
substituted.
The %luser% substitutes the login name of the local user on the remote
host. Normally, it is the same as %ruser%, unless the -l option of the
rsh command was used. Then, this will contain the actual user login
used at the remote host.
For example, if you are logged in as "john" on a remote host and you
issue the command "rsh -l mary winpc xyz", the %ruser% will
substitute "mary" and the %luser% will substitute "john".
The %rhost% substitutes the host name of the remote host, if it is
available. That is, RSHD/NT must be able to find the name of the
remote host based on its IP address, either by using the HOSTS file
or DNS. If it is not found, the IP address will be substituted.
These special keywords allow you to have different environment files
for different users if necessary. For example, if you specify the
environment variable file:
c:\env\%ruser%.env
When "john" issues an rsh command, RSHD/NT will get the environment
from the file "c:\env\john.env". When "mary" issues an rsh command,
RSHD/NT will get the environment from the file "c:\env\mary.env".
Also, using the capability to specify multiple files, you can have a
single "master" environment, and then only modifications to it by user.
For example, you can have a standard set of environment variables in
the file "c:\env\master.env" and user-specific modifications in the
file "c:\env\%ruser%.env". Your environment variable file field
would read:
c:\env\master.env;c:\env\%ruser%.env
First the variables in master.env would be read, then those for the
user in %ruser%.env.
THE SPECIAL "new" KEYWORD
The format of the environment variable files must be:
VARIABLE=VALUE
But, with one exception. If you specify the word "new" on a line
by itself in an environment variable file, it will purge all
environment variables set up to that point.
The primary purpose of this would be to remove all variables
inherited from the System Environment Variables. It allows you to
start with a "clean slate" and set all environment variables
from scratch.
Default Command Shell: (Default: Blank - Use "CMD /C")
This option allows you to specify the default command shell to be
used when RSHD/NT detects an internal command or the command shell to
be used if the option to Execute All Commands through Command Shell
is checked.
You should use this option only if you are using an alternate command
shell. By default, RSHD/NT uses the Windows NT command shell CMD.EXE.
You must specify all necessary options to the command shell so that
it can be prefixed to any command (internal or external).
If you end the command with a single-quote (') or double-quote ("),
RSHD/NT will supply the closing quote, enclosing the command
received from rsh in quotes. This is necessary for some shells
that will interpret command line options as their own, such as
the Bourne shell. If you were using the Bourne shell (or Korn
shell, you would enter the following:
sh -c "
In this case, for example, the command:
rsh ntsystem ls -l
Would execute the following through RSHD/NT:
sh -c "ls -l"
If the trailing quote was not present, it would execute:
sh -c ls -l
And "sh" would interpret the "-l" as an option to itself instead
of as an option to "ls".
Internal Command List: (Default: Blank)
If you specified a Default Command Shell that has different internal
commands than those of the standard Windows NT command shell CMD.EXE,
you can specify the internal commands for that shell here. Separate
each command with a comma (,). Do not include any spaces.
If you checked the option to Disable Detection of Internal Commands,
this is not necessary and will have no effect.
You only need to specify this list if you want RSHD/NT to recognize
commands internal to your command shell and automatically prefix the
command with the appropriate shell command.
Buffer Stdout/Stderr Until End of Command? (Default: Unchecked)
Check this option if you want RSHD/NT to buffer (store in a file)
the standard output and standard error output of the commands you
execute, and then send all of the output when the command completes.
Prior to Version 2.0, this was the standard behavior of RSHD/NT.
With Version 2.0, the standard output and standard error is sent as
it occurs (although it may be buffered by Windows NT or the program
executed). If you check this option, RSHD/NT will operate as it did
in previous versions.
Disable Detection of Internal Commands?: (Default: Unchecked)
When you execute a command via RSH through RSHD/NT, it will
examine the command and determine whether or not it is a
Windows NT "internal command". That is, the command does not
actually exist as an executable file, but is interpreted by
the Windows NT Command Interpreter (CMD.EXE). Some examples
of internal commands are DIR, TYPE, and SET.
If RSHD/NT determines that it is an internal command, it will
prefix the command with "CMD /C" so that it executes properly.
However, if you are using an alternate command interpeter, you
may not want this to occur, so you can disable the examination
of the commands by checking this option.
Default Window Type for Commands Executed with RSH: (Default: Normal)
Specifies the default window type to be used when executing
commands through Winsock RSHD/NT using the rsh command. The
default window type is used when the special window type
indicators (<[NORMAL]>, <[MINIMIZE]>, <[MAXIMIZE]>, <[HIDE]>,
etc.) are not specified in the rsh command.
The options available are:
Normal: The window for the command will display at its normal size.
Minimized: The window for the command will be minimized (without focus).
Maximized: The window for the command will be maximized.
Hidden: The window for the command will be hidden.
There are a few points you must consider when selecting the
default window type:
- The Minimized or Hidden options are useful when the system
running RSHD/NT is actively used and is not a standalone server.
With the Normal or Maximized options, the person using the system
will see a window appear each time a command is executed through
rsh.
- You cannot send keystrokes to commands that are minimized or
hidden. So if you select the Minimized or Hidden option, you must
override it in the rsh command when you want to send keystrokes.
That is, you will need to add the <[NORMAL]> option to the
command.
- Using the Hidden option can cause administrative problems.
When a program's window is hidden, it does not appear in the Task
List, so there is not an easy way to stop a hidden program or to
tell if any are running. There are utilities that allow you to
see the hidden programs (such as the PView program that comes with
Microsoft Visual C/C++).
RCP OPTIONS
Reject All RCP Copies to This System: (Default: Not Checked)
If this option is checked, all attempts to copy files to this system
with the rcp command will be rejected with an error message stating
that incoming copies are disabled. This allows you to make the system
"read only" when using the rcp command.
You can also reject copying from the system, essentially disabling the
rcp capability of RSHD/NT.
Reject All RCP Copies to From System: (Default: Not Checked)
If this option is checked, all attempts to copy files from this
system with the rcp command will be rejected with an error message
stating that outgoing copies are disabled. This allows you to make
the system "write only" when using the rcp command.
You can also reject copying to the system, essentially disabling the
rcp capability of RSHD/NT.
Preserve Case in Multi-File Copies: (Default: Unchecked)
Specifies whether Winsock RSHD/NT should preserve the case of
filenames when files are copied from this system by rcp using
wildcards or recursive copies. By default, when the remote
system uses a wildcard or recursive copy to get files from
this PC, Winsock RSHD/NT will convert all directory and
filenames to lowercase letters before sending them to the
remote system.
Although the Windows NT filesystem is not case sensitive (ABC
and abc are the same file), it can store the case of the
filename. When copying files via rcp to operating systems
that are case sensitive, such as Unix, it is usually most
useful to convert all of the names to lowercase letters.
If you do not wish to have all of the names converted to
lowercase letters, check this option. The rcp command will
then create files in exactly the same case as the names
appear in the directory under Windows NT.
Note that this affects only wildcard and recursive copies.
When copying individual files, the files will be created in
the case you specify in the rcp command.
Automatic End-of-Line Conversion: (Default: Not Checked - Never)
Specifies whether or not RSHD/NT should perform any end-of-line
conversions on files transferred to or from the NT system using rcp.
Under MS-DOS, Windows 3.x, Windows 95, and Windows NT, lines of text
are delimited by carriage return and newline pairs (ASCII 13 and
ASCII 10). Under Unix, lines of text are delimited by only newlines
(ASCII 10). Often, when copying text files between the two operating
systems, it is necessary to convert the end-of-line delimiters to the
proper method. RSHD/NT provides a way to automatically do this.
When files are copied from the NT system through RSHD/NT, carriage
returns will be removed from all carriage return/newline pairs
(i.e. converted to Unix format). When files are copied to the NT
system through RSHD/NT, carriage returns will be added to every
newline character that is not already prefixed by a carriage return
(i.e. converted to NT format).
There are four options available. The option you select affects all
rcp copies to this system and all rcp copies from the system. It does
not affect the operation of the rcp command itself on the NT system.
It only affects the result of rcp commands that access files
on this system from other systems.
- Never - Copy all files as binary
No end-of-line conversion will be done. All files will be transferred
or received unmodified.
- Always - Convert all files
Convert the end-of-line characters on every file copied from or to
this system through RSHD/NT.
- Convert based on list of file extentions
Only convert end-of-line characters in files ending with the
specified list of file extensions. You must then enter the list of
file extensions. Separate each file extension by a comma. Do not
include any spaces. You must include the "dot" (.). For example:
.TXT,.C,.H,.PRN,.MAK
Any file not ending in one of these extensions will be copied without
modification.
- Convert based on contents of first block
RSHD/NT will examine the contents of the first block of the file to
be sent or received and determine whether or not an end-of-line
conversion is necessary. If the first block contains only text
characters (letters, numbers, spaces, tabs, carriage returns, newlines,
backspaces, escapes, and form feeds), RSHD/NT will perform
an end-of-line conversion on the file. If the first block contains
any other non-text data, it will be copied without modification.
The size of the first block is specified in the RCP Block Size field.
RCP Home Directory: (Default: Blank)
Specifies the starting directory where files will be copied from or
to when a relative path name is used in an rcp command (no initial
slash or backslash).
This directory must exist if specified. The directory name specified
can contain the following special keywords:
%ruser% - Substitute the login name of the remote user
%luser% - Substitute the login name of the local user
%rhost% - Substitute the host name of the remote host
The %ruser% substitutes the login name of the remote user. This will
be the login name the user used to log into the remote host from which
the rcp command is being issued, unless the @ option of the rcp command
was used to specify a different user; then that user will be
substituted (e.g. user@host:filename).
The %luser% substitutes the login name of the local user on the remote
host. Normally, it is the same as %ruser%, unless the @ option of the
rcp command was used. Then, this will contain the actual user login
used at the remote host.
For example, if you are logged in as "john" on a remote host and you
issue the command "rcp xyz mary@winpc:", the %ruser% will substitute
"mary" and the %luser% will substitute "john".
The %rhost% substitutes the host name of the remote host, if it is
available. That is, RSHD/NT must be able to find the name of theo
remote host based on its IP address, either by using the HOSTS file
or DNS. If it is not found, the IP address will be substituted.
RCP Block Size: (Default: 512)
Specifies the number of bytes in a block of data that the
Remote Copy (rcp) service of Winsock RSHD/NT processes at one
time. When files are copied to the PC, it reads from the
network and writes to the disk in blocks of this size. When
files are copied from the PC, it reads from the disk and
writes to the network in blocks of this size. Note that this
is an internal block size only; it does not change any TCP/IP
parameters.
RCP Spoofing Prefix: (Default: <blank>)
Specifies the first characters of the rcp command send by the
remote host that Winsock RSHD/NT should use when "spoofing"
the RCP protocol. With its roots in Unix, the rcp command
actually internally executes an rsh command to start rcp on
the remote host before transferring files. Winsock RSHD/NT
"spoofs" or looks for rcp commands executed through rsh by
the remote host and services the RCP transfer.
By default, Winsock RSHD/NT looks for the command prefixes of:
rcp -
/usr/bin/rcp -
/usr/lib/sunw,rcp -
set vms_rcp = 1 ; rcp -
Some rcp commands (especially those on non-Unix and non-Windows
systems) may send other commands to initiate the RCP protocol.
If yours does, you should enter the command prefix (up to and
including the first hyphen) here.
Regardless of the spoofing prefix entered, Winsock RSHD/NT
will continue to look for the above prefixes.
Execute All RCP Copies as User: (Default: <blank>)
Password:
Normally, all files read or written to by RSHD/NT via the RCP
command are done so in the context of the user specified in the
RSHD/NT service setup (by default, this is the user System).
You can change the service setup to execute RSHD/NT as any user.
However, when you run RSHD/NT as a user other than System, you lose
access to the NT workstation desktop. This means that the special
"send keys" option of the RSH command will no longer work.
To enforce security on RCP commands, but retain the ability to send
keys to programs through RSH, you can specify a valid user and password
in these fields. If you do, RSHD/NT will log in as that user and
read and write all files as that user when servicing the RCP command.
All security restrictions on that user will be enforced when files are
read as a result of an RCP command. All files created by an RCP
command will be owned by that user.
If you need to specify a domain name along with the user, specify
it in the format "domain\user". Otherwise, the domain of the current
system will be used.
If you specify an invalid password, all RCP copies will fail. Also,
if the specified user's password expires or is changed, you will need
to manually update the password here. NT does not do it automatically.
It is best to specify that the user's password does not expire to
avoid this.
ADVANCED OPTIONS
Installation Directory:
This is the directory where RSHD/NT is installed. If you move the
RSHD/NT directory, you can update this field.
Initial Working Directory: (Default: Instalation Directory)
This specifies the directory that will initially be considered the
current working directory for all commands executed using rsh. It will
also be considered the current working directory for all files copied
using rcp, unless an RCP Home Directory is specified.
When RSHD/NT starts, it changes to this directory and remains there,
unless an rsh request is received to execute the cd or chdir command,
which will change RSHD/NT's working directory.
Note that a cd or chdir command will change RSHD/NT's working directory
for all subsequent commands, regardless of the user or system they are
executed from.
Disable Multithreading in RSHD: (Default: Unchecked)
Multithreading allows Winsock RSHD/NT to process multiple
requests simultaneously. When multithreading is disabled by
checking this option, Winsock RSHD/NT will accept and
complete only one request at a time. Other requests received
during this time will be queued and executed in the order in
which they were received. Normally, you will want
multithreading enabled, but you can disable it, for example,
to ensure that the system will not become bogged down with
requests.
Disable Monitoring of Registry for Changes: (Default: Unchecked)
Normally, Winsock RSHD/NT starts a thread that monitors the
Windows Registry for changes to the Winsock RSHD/NT
configuration options and if any options are changed, re-
reads the registry so that the new options take effect.
If this option is check to disable the monitoring of the
Registry, you must stop and start Winsock RSHD/NT manually
(or by rebooting the system) for the Registry changes to take
effect.
You may want the Registry monitoring disabled for security
purposes so that no Winsock RHSD/NT options are changed while
the system is in operation.
Host IP Address (If Multi-Homed): (Default: None)
If your system is multi-homed (it has multiple network cards,
each with its own IP address), you can specify which IP
address RSHD/NT will use to listen for requests. If you
leave this empty, it will accept requests from any of the IP
addresses associated with the system. If you specify one of
the addresses of one of the cards (in dotted-decimal format),
it will only accept requests routed to that address.
Listen Port: (Default: 514)
Specifies the port number that Winsock RSHD/NT listens to for
connections. The standard port for the Remote Shell daemon
is 514.
Listen Backlog: (Default: 100)
The number of requests that can be backlogged when Winsock
RSHD/NT is listening for connections. The minimum is 1; the
maximum for Windows NT is 100.
WINSOCK RSHD/NT SECURITY FILE
With Unix, security is enforced on remote command execution using
a combination of the password file (/etc/passwd), the hosts file
(/etc/hosts),and the host equivalency files (/etc/hosts.equiv and
$HOME/.rhosts).
Winsock RSHD/NT enforces security through the Security File. The
name of this file is specified in the Winsock RSHD/NT
Configuration in the Security File entry.
If you specify a Security File name and the file does not exist or
the file is completely empty, all hosts and users are denied
access.
Conversely, if you do not specify a Security File, all hosts and
users are granted access. So if you do not wish to enforce any
security, do not specify a Security File name in the configuration
file.
Additionally, you can configure Winsock RSHD/NT to ensure that
user names on remote hosts are valid on this system. You should
only enable this security option if you use consistent user names
across all of the systems on your network.
You create the Security File using a text editor. If you are
using the Winsock RSHD/NT Control Panel applet, you can click on
the Edit Security button to run the Windows Notepad editor to edit
the security file specified in the Security File configuration
option.
The Security File consists of lines that specify who may or may
not access the PC using Winsock RSHD/NT. The following are the
options available in:
#
Any line beginning with # is treated as a comment and is
ignored.
+
A plus sign (+) on a line by itself specifies that ALL hosts
and users are granted permission. This is useful if you wish
to allow many hosts and users, but deny only a few. Use the
deny options on subsequent lines.
host
You can specify a host that is granted permission by entering
the name of the host on a line by itself. All users on that
host are granted permission, unless you specifically deny
those users on subsequent lines.
You may also use the IP address of the host instead (the
dotted-decimal representation). If you specify the name of
the host, that name must appear in the hosts file used by
your TCP/IP package.
!host
You can specify a host that is denied permission by entering
an exclamation point (!) followed by the name of the host
name of the host on a line. All users on that host are
denied permission, regardless of subsequent lines.
You may also use the IP address of the host instead (the
dotted-decimal representation). If you specify the name of
the host, that name must appear in the hosts file used by
your TCP/IP package.
+user
You can specify a user name that is granted permission by
entering a plus sign (+) followed by the user name on a line.
Do not put any spaces between the plus sign and the user
name. That user will be granted permission regardless of the
host (as long as the host is not specifically denied).
See below for an explanation of the source of the user name
and how it is validated.
-user
You can specify a user name that is to be denied permission
by entering a minus sign (-) followed by the user name on a
line. Do not put any spaces between the plus sign and the
user name. That user will be denied permission on all hosts.
See below for an explanation of the source of the user name
and how it is validated.
+user@host
You can specify a user name and a host that is granted
permission by entering a plus sign (+) followed by the user
name, an at-sign (@), followed by the host name on a line.
Do not put any spaces between the plus sign and the user name
or before or after the at-sign. That user on the specified
host will be granted permission, but only from that host.
You may also use the IP address of the host instead (the
dotted-decimal representation). If you specify the name of
the host, that name must appear in the hosts file used by
your TCP/IP package.
-user@host
You can specify a user name and a host that is denied
permission by entering a minus sign (-) followed by the user
name, an at-sign (@), followed by the host name on a line.
Do not put any spaces between the minus sign and the user
name or before or after the
at-sign. That user on the specified host will be denied
permission, but only when coming from that host.
You may also use the IP address of the host instead (the
dotted-decimal representation). If you specify the name of
the host, that name must appear in the hosts on the Windows
NT system.
If the request is coming from a Unix system, the user name is the
login name of the user. If the request is coming from another
Windows PC, the method of specifying the user name is determined
by the implementation of the rsh or rcp command you are using.
Note that the standard Unix rsh command (and the Winsock RSH
command available from Denicomp Systems) allows a "-l" option to
specify an alternate user name. The "-l" option has meaning on a
Unix system, but is not especially useful with Winsock RSHD/NT.
However, if you do use the "-l" option to specify an alternate
user, as with Unix, that user must be granted permission through
the Security File in addition to the login name (Unix) or the name
specified in your particular TCP/IP implementation (Windows/DOS).
USING THE SECURITY FILE
To effectively use the Security File, you must first understand
how it is viewed by Winsock RSHD/NT.
When Winsock RSHD/NT receives a request, it sequentially processes
the lines in the Security File to determine whether or not the
host and user are granted or denied access. It looks at each line
in the Security File until it determines that either the host or
the user is specifically denied permission.
Winsock RSHD/NT begins by assuming that permission is denied for
the request. It then examines the lines in the Security File to
see if any of the lines pertain to this request.
Once Winsock RSHD/NT finds a line that denies access to either the
user or the host, it stops looking and denies permission.
If it finds a line that grants permission to the user and/or host,
permission is tentatively granted, but it continues to process the
lines in the Security File.
If it processes the entire Security File and does not find a line
that grants permission to the user and/or the host, permission is
denied. If security was tentatively granted at some point and
not denied subsequently, permission is granted.
For example, let's say that the following is the contents of the
Security File:
jetty
booey
eib
192.56.42.3
rs6000
+fred@mars
-gary@booey
-jackie
+robin
In this example, if any user on the host "jetty" makes a request,
permission will be granted, unless the user is "jackie", since
"jackie" is denied access from all hosts (-jackie).
If "jackie@jetty" makes a request, Winsock RSHD/NT reads through
the Security File and finds the host name "jetty", and tentatively
grants permission. However, it continues and finds that the user
"jackie" is denied from all hosts, so permission is denied.
Also, if any user on the host "booey" makes a request, they are
granted permission unless the user is "gary", since "gary@booey"
is specifically denied permission (-gary@booey). All other users
on the host "booey" are granted permission except "jackie" (-
jackie).
The user "fred" on the host "mars" is granted permission because
of the line "+fred@mars". However, since the host "mars" does not
appear on a line by itself, no other users on the host "mars" are
granted permission except the user "robin", who is granted
permission from any host (+robin).
RSHD/NT AND NTFS SECURITY
Under Unix, the Remote Shell Daemon process (rshd) implements
security through user equivalence. That is, it is assumed that
when an rcp or rsh command is executed by the user "john" on a
client system, the user "john" exists on the host system and has
the appropriate privileges.
Under Unix, the Remote Shell Daemon process (rshd) runs as the
super-user, root. Unix has a feature known as "set user id" or
"setuid". When you execute an rsh or rcp, the Unix rshd
effectively "becomes" the user passed to it by rcp or rsh. Any
process spawned (rsh) or file accessed/created (rcp) are done so
as if that user were logged on to the system, taking on the
security attributes of that user.
Windows NT has a similar capability (called "impersonation" in NT
lingo). However, there is a basic, but important difference. In
order for a process like RSHD/NT to "become" another user, that
user's password must be supplied. This is incompatible with rcp
and rsh - they cannot ask for a password. So it is not possible
for RSHD/NT to mirror this feature of Unix's rshd.
When RSHD/NT is installed by its SETUP program, an NT service is
created and is set up to run RSHD/NT as the user System, which is
a privileged account. Any files accessed by RSHD/NT will be
accessed as the user System and any programs spawned will be done
so as the user System.
If you need to restrict access through RSHD/NT, you can change the
setup of the RSHD/NT service using the Services applet in the
Control Panel. You can specify an account other than System and
RSHD/NT will execute with the security attributes of that user.
All rcp and rsh commands serviced will be restricted to the
privileges of that user.
You can specify the account name of an existing user. However,
this can cause problems because you must also specify that user's
password in the Service setup. If that user's password expires or
changes, you must remember to manually change it in the Service
setup at that time or RSHD/NT will not start. NT will not update
the Service setup automatically.
An alternative is to set up a new account specifically for the
purpose of running RSHD/NT. Specify that the account's password
does not expire so it will not be forced to change. You can then
set up the security attributes of that user and they will be
inherited by all rsh and rcp commands serviced by RSHD/NT. (This
is similar to the way NT's FTP Server implements security for
anonymous users.)
This will then allow you to restrict the files accessible by users
using rcp and rsh. It is not totally ideal because all users will
be given the same access rights. But it is a necessary compromise
because of the basic differences between NT and Unix.
EXECUTING COMMANDS
With Unix, the rsh utility executes the specified command on a
remote host and returns the standard output and the standard error
output to the requesting host.
With Windows, there is no such thing as "standard output" and
"standard error". Programs execute in graphical windows, so there
is no way to return any output using rsh.
Therefore, when using rsh from Unix or another PC to initiate
commands on a Windows PC, you will not see any output of the
command on your screen. It will display on the PC that received
the request.
For example, if you used the following command:
rsh winpc3 excel
This would start Excel on the PC named "winpc3". You would see
nothing on your screen as a result of starting Excel. Excel would
be running on the screen of the PC named "winpc3".
The rsh command will NOT wait for the specified command to
complete. The system issuing the request will regain control
immediately after the command begins.
If you attempt to execute a command that does not exist or Windows
returns an error trying to load the program, you will receive a
descriptive error message on your screen from Winsock RSHD/NT to
tell you that the command was not successfully executed.
Important Note: Winsock RSHD/NT uses the PATH and other
environment variables specified in the Control Panel for the
entire system, not for a specific user. If you are trying to
execute a command that Winsock RSHD/NT cannot find, check the
System environment variables.
SENDING KEYSTROKES
Winsock RSHD/NT provides the ability for you to send keystrokes to
the Windows application you initiate using the rsh command. It
also allows you to specify how the window is to be displayed
(i.e., normal, minimized, maximized, or hidden). This provides
you with some "remote control" over what the program you run does
once it starts.
For those of you who program in Microsoft Visual Basic or the
Visual Basic for Applications macro language, this is very similar
to the SendKeys capability of those programming languages.
The standard syntax of the rsh command is:
rsh hostname command
This will execute "command" on the host "hostname". Winsock
RSHD/NT allows a slight modification of the rsh syntax to send
keystrokes. This is compatible with all rsh commands. The
alternative syntax for sending keystrokes is:
rsh hostname "<keystrokes>" command
If the first parameter after the host name begins with a less-than
sign (<), that parameter is interpreted as keystrokes to be sent
to the command specified in the next parameter. The keystrokes
must end with a greater-than sign (>). You must also enclose the
entire parameter in quotes so special characters and spaces are
not interpreted by the operating system.
For example, if you wanted to run the Windows Notepad on the PC
named "winpc3" and type "This is a test" on the first line, the
command would be:
rsh winpc3 "<This is a test>" notepad
If you looked at the winpc3's screen, you would see the Windows
Notepad with "This is a test" on the first line.
You cannot send keystrokes to an application that is not designed
to run in Microsoft Windows (i.e., MS-DOS programs).
Important Note: Due to a limitation in Windows NT, you cannot
send keystrokes to an application started through Winsock RSHD/NT
if there is no one logged in to Windows NT. The program will be
executed, but it will not receive the keystrokes.
SENDING SPECIAL KEYSTROKES
Winsock RSHD/NT also allows you to specify special keys in the
keystrokes parameter that cannot normally be typed on a command
line, such as embedded Enter keys, function keys, ALT keys, etc.
Keystrokes are sent sequentially as the appear between the "<" and
">". To send a single character, use the character itself. For
example, to send the letter "X", use the letter "X". To send the
word "hello", just specify those letters.
To specify keys combined with any combination of Shift, Ctrl, and
Alt keys, prefix the regular key code to one or more of the
following codes:
Shift +
Control ^
Alt %
For example, to send the Alt-F keystroke, specify "%F". To send
Ctrl-Alt-D, specify "^%D".
To send the Enter key, use the tilde (~).
To specify that the Shift, Ctrl, and/or Alt keys should be held
down while several other keys are pressed, enclose the key codes
in parentheses ( ). For example, to have the Alt key held down
while X and D are pressed, use "%(XD)". You could also use
"%X%D", but if the Shift, Ctrl, and/or Alt keys need to be held
down for a number of keystrokes, the parentheses can make the
string shorter. Also, you would want to use the parentheses if
the application
detects the release of the Shift, Ctrl, and/or Alt keys and that
is not desired.
The following characters have special meaning in the keystroke
parameter, so they must be enclosed inside braces ({ }). Some of
these special characters have not been explained yet.
Special Character Example
+ (plus) {+}
^ (caret) {^}
% (percent) {%}
~ (tilde) {~}
< (less than) {<}
> (greater than) {>}
[ (left sq. bracket) {[}
] (right sq. bracket) {]}
( (left paren) {(}
) (right paren) {)}
@ (at-sign) {@}
{ (left brace) {{}
} (right brace) {}}
To send characters that are not normally displayed when you press
a key (such as Enter or Tab) and keys that represent actions
rather than characters, use the following special codes:
Key Code Key Code
Backspace {BACKSPACE} or {BS} Break {BREAK}
Caps Lock {CAPSLOCK} Clear {CLEAR}
Del {DELETE} or {DEL} Down Arrow {DOWN}
End {END} Enter {ENTER} or ~
Esc {ESCAPE} or {ESC} Help {HELP}
Home {HOME} Ins {INSERT}
Left Arrow {LEFT} Num Lock {NUMLOCK}
Page Down {PGDN} Page Up {PGUP}
Print Screen {PRTSC} Right Arrow {RIGHT}
Scroll Lock {SCROLLLOCK} Tab {TAB}
Up Arrow {UP} F1 {F1}
F2 {F2} F3 {F3}
F4 {F4} F5 {F5}
F6 {F6} F7 {F7}
F8 {F8} F9 {F9}
F10 {F10} F11 {F11}
F12 {F12} F13 {F13}
F14 {F14} F15 {F15}
F16 {F16}
You can also specify that a key is to repeat itself a certain
number of times, without repeating the key itself in the string.
To repeat a keystroke, use the format:
{keystroke number}
Where "keystroke" is the key to repeat, followed by a single
space, then the number of times to repeat the key.
For example, to press the down arrow key eight times, use "{DOWN
8}".
To type thirty *'s, use "{* 30}".
PAUSING WITHIN KEYSTROKES
Under some circumstances, it may be necessary to pause for a
specific time before sending keystrokes to allow a program
operation to complete. This is usually necessary when a program
ignores keystrokes that have been queued while a lengthly
operation takes place.
Within the keystroke list, you can specify pauses by using the
special {PAUSE #} keystroke.
This is not actually a keystroke, in that it does not press any
key, but it can be included anywhere within the keystroke list.
It will pause the specified number of seconds.
For example, the following keystroke list will press Alt-F, P,
wait 10 seconds, then press Alt-F, X:
<%FP{PAUSE 10}%FX>
You can specify multiple pauses in the keystroke list if
necessary.
Note: A pause of one second is automatically added at the
beginning of the list of keystrokes when the Attempt Redirection
on Every Command option is enabled in the Control Panel. When
this option is enabled, all commands are executed through the NT
command interpreter. Adding the one second pause gives the
command interpreter time to start so that it does not receive the
keystrokes instead of the program you want to execute. If your NT
system is extremely slow, you may need to add an additional pause
to the beginning of the keystroke list if you find that the one
second pause is not enough.
KEYSTROKE EXAMPLE
The following example, will start Microsoft Word, load a file,
print it, then exit.
rsh winpc3 "<%FO\docs\invoice.doc~%FP~%FX>" word
The keystrokes are:
%F - Alt-F (Drops down the file menu)
O - O (Selects Open)
\docs\invoice.doc - Types the filename.
~ - Enter (Loads the File)
%F - Alt-F (Drops down the file menu)
P - P (Selects Print)
~ - Enter (Accepts the defaults on the Print dialog box)
%F - Alt-F (Drops down the file menu)
X - X (Selects eXit and Word exits)
Note that if this example were being run from a Unix system, you
would have to use two backslashes (\\) for every one desired
backslash because the Unix shells interpret the backslashes as
special characters. The command would then be:
rsh winpc3 "<%FO\\docs\\invoice.doc~%FP~%FX>" word
KEYSTROKE MACRO FILES
If your keystroke strings get rather long or complex, you can
store them in a keystroke macro file so you do not have to specify
all of them each time you use the rsh command.
To create a keystroke macro file, you must use a text editor (or a
word processor, but be sure to save as an ASCII file). Enter the
keystrokes as you would on the rsh command line, with the
following exceptions/reminders:
- Do not enter "<" as the first character in the file or ">"
as the last character. All of the characters you enter in
the file will be sent.
- You may press Enter in the file to enter the keystrokes on
multiple lines. The line breaks have no effect on the
keystrokes. They will be treated as if they were entered all
on the same line. That is, you must remember to still use
"~" or "{ENTER}" to "press" the Enter key. Pressing Enter in
the file will not send the Enter key.
- You cannot nest keystroke macros. Your macro file cannot
contain references to other keystroke macro files.
- The keystroke macro file must reside on the PC running
Winsock RSHD/NT. You can create the file on that PC or use
rcp to copy it to that PC before executing the command.
To use a keystroke macro file, enter the at-sign (@) followed by
the filename in braces ({ }) where you would normally specify
keystrokes on the rsh command line.
You will most likely need to specify a full pathname of the
keystroke file on the PC running Winsock RSHD/NT, unless you know
the working directory of Winsock RSHD/NT on the system running it
and the keystroke macro resides in that directory. You may use
forward slashes (/) instead of backslashes if you wish; this makes
life easier for Unix users because the shell interprets the
backslash characters.
For example, if you had a macro in the directory
\kbmac\printss.mac on the PC running Winsock RSHD/NT, you could
use it with this command:
rsh winpc2 "<@{/kbmac/printss.mac}>" excel
This would run "excel" on winpc2 and send the keystrokes stored in
the file \kbmac\printss.mac to it.
You can intermix command line keystrokes and macro file
keystrokes. That is, you can specify some of the keystrokes on
the command line and use some from a macro file. You can also
use multiple macro files.
For example, let's say we want to print a file using rsh through a
Windows application called "wintiff". We want to store the
keystrokes in a macro file, but do not want to store the filename
in the macro file because it can change.
To do this you can store the first set of keystrokes in one macro
file, specify the filename on the rsh command line, then store the
remaining keystrokes in a second file.
For example, let's say the file is "mypic.tif":
rcp mypic.tif winpc2:/tmp
rsh winpc2 "<@{/kb/tif1.mac}\tmp\mypic.tif~@{/kb/tif2.mac}"
wintiff
This example copies the file "mypic.tif" to the \tmp directory on
winpc2. Then it runs "wintiff" and first sends the keystrokes
from the file \kb\tif1.mac. That macro ends when "wintiff"
requires a filename. The keystrokes to "type" the filename come
from the rsh
command line since the tif1.mac has ended. Then it continues by
sending the keystrokes in the file \kb\tif2.mac. That is:
@{/kb/tif1.mac} - Send keystrokes from \kb\tif1.mac
\tmp\mypic.tif~ - Type \tmp\mypic.tif and press Enter
@{/kb/tif2.mac} - Send keystrokes from \kb\tif2.mac
SPECIFYING THE WINDOW TYPE
Winsock RSHD/NT also allows you to specify the window type of the
application being run. Normally, the application is run based on
the default window type specified in the Control Panel.
If you want to specify a different method of displaying the
application's window, you can specify this inside the keystroke
parameter by enclosing the method in square brackets ([ ]).
There are two methods of setting the window type. You can use one
of the words shown below or you can use a number. The options
are:
Window Option Displays
NORMAL or NORM Normal Display as defined by the application
MINIMIZE or MIN Shows the application as a minimized icon without focus
MINACTIVE or MINA Shows the application as a minimized icon with focus
MAXIMIZE or MAX Maximizes the application on startup
HIDE Hides the application (no icon appears)
0 Same as HIDE
1 Same as NORMAL
7 Same as MINIMIZE
2 Same as MINACTIVE
3 Same as MAXIMIZE
Other numeric values may be used - they correspond to the Windows'
ShowWindow function (for all you programmers).
For example, if you want to run the Windows Notepad maximized,
viewing the file "heyyou.txt", you would type:
rsh winpc3 "<[MAXIMIZE]>%FOheyyou.txt~" notepad
This runs the Notepad maximized, then "presses" Alt-F-O (File
Open) and types the filename "heyyou.txt" and presses Enter to
load it.
If you wanted to run some application that does some task and
exits, you could run it minimized using:
rsh winpc3 "<[MINIMIZE]>" bkgprint
Note that Windows does not allow you to send keystrokes to a
minimized or hidden application. Therefore, "[MINIMIZE]",
"[HIDE]", "[0]", or "[2]" should always appear alone between the
"<" and ">". If you specify other keystrokes, the application
will not receive them (Windows will beep at you for each
keystroke).
WAITING FOR COMMANDS TO COMPLETE
By default, Winsock RSHD/NT returns control back to the system
issuing the command via rsh immediately after the command is
started and any keystrokes are sent. It does not wait for the
command to complete.
If you want the rsh command to wait until the command finishes
executing, you can use the "[WAIT]" option. This is specified
like the Window Type, as explained in the previous section.
For example, to execute the command "bkgprint" and wait for it to
finish, use:
rsh winpc3 "<[WAIT]>" bkgprint
As with the Window Type, you can combine options and keystrokes.
This runs the above command, but minimizes it and waits:
rsh winpc3 "<[MINIMIZE][WAIT]>" bkgprint
Note that Winsock RSHD/NT cannot process other command requests
when you instruct it to wait for a command to complete. If other
users issue commands to the PC while it is waiting, they will be
queued until Winsock RSHD/NT can process them. The number of
requests that can be queued depends on the Listen Backlog
parameter explained in the Winsock RSHD/NT Configuration section.
EXECUTING MS-DOS "INTERNAL" COMMANDS
Some commands that you can execute at Windows NT's Command Prompt
are not actually programs; they are internally recognized by the
command interpreter CMD.EXE. One example of this is the DIR
command. If you look in the directory where Windows NT is
installed, there will be no DIR.EXE. It is part of CMD.EXE.
In previous versions of Winsock RSHD/NT, you had to prefix these
internal commands with "cmd /c". Winsock RSHD/NT now recognizes
internal commands and will execute them through the NT command
interpreter. Prefixing the commands with "cmd /c" is no longer
necessary, although it will still work if you do.
CAPTURING STANDARD OUTPUT AND STANDARD ERROR
You can optionally capture the standard output and standard error
output of Windows NT Console or MS-DOS commands through Winsock
RSHD/NT with the rsh command. This allows you to display the
output of these programs that output to the standard output or
standard error on another screen or capture it to a file on
another system.
To do this, you must tell Winsock RSHD/NT that you are executing a
Console or MS-DOS command. Winsock RSHD/NT cannot tell whether
the command you issue is a Windows program or a Console/MS-DOS
program until it starts executing it (and by then, it's too
late!).
To capture the standard output/standard error of a command, use
the "[CON]" option in the rsh command. For example:
rsh winpc3 "<[CON]>" net view
This will run the "net view" command on "winpc3" and display the
output on the your screen. The "net view" command displays
information on the standard output. Note that if your command
requires any command line switches, place a space between the
command name and the switch. For example, use "mem /c", not
"mem/c".
Note: There is a configuration option that tells Winsock RSHD/NT
to assume the "<[CON]>" option on every command and capture the
standard output and standard error. If this option is enabled,
you do not need to specify the "<[CON]>" option.
If you are on a Unix system and you want to store the output of
the "net view" command in a file, you can use the following
command:
rsh winpc3 "<[CON]>" net view > net.out
In this example, the file "net.out" will be created on the Unix
system, the system where the rsh command originated. The ">
net.out" part of the command is not passed to "winpc3" because the
Unix shell interprets it first.
If you are using a Windows system and you want to do the same
thing, you must refer to the instructions for the implementation
of the rsh command you are using. Windows does not support
redirection, but MS-DOS does. If your rsh command is MS-DOS
based, the above
command may work from a DOS prompt. If you are using Denicomp
Systems's Winsock RSH, you could do the above within Windows with
the following command:
rsh winpc -r net.out "<[CON]>" net view
Note that some MS-DOS programs do not write to the standard
output; instead they directly write to video memory. Output from
these programs cannot be captured.
If you have enabled the option to Buffer Standard Output/Standard Error
until the end of the command, the standard output will be sent first,
then the standard error output. You can reverse this order by using
"<[CON2]>" in place of "<[CON]>".
To maintain compatibility with the Windows 3.1 version of Winsock
RSHD/NT, you may also use "[DOS]" or "[DOS2]" in place of "[CON]"
and "[CON2]".
DISABLING THE CAPTURE OF STANDARD OUTPUT AND STANDARD ERROR
There is a configuration option that tells Winsock RSHD/NT to
assume the "<[CON]>" option on every rsh command and attempt to
capture the standard output and standard error. This is useful if
you mostly execute Windows NT Console and MS-DOS programs.
Howver, this can cause problems when you need to execute a Windows
program. If this option is enabled, you cannot send keystrokes to
the program and Winsock RSHD/NT will automatically wait for the
command to complete. There is also some additional overhead
involved in running the program.
If you have enable this option to assume the "<[CON]>" option and
you need to run a Windows program and send keystrokes to it or you
do not want rsh to wait for it to complete, specif the "<[WIN]>"
option in the rsh command line. This option overrides the assumed
"<[CON]>" option for the command. For example:
rsh winpc "<[WIN]%FP~%FX>" excel abc.xls
This will run the command "excel abc.xls" on winpc as a Windows
program and send the specified keystrokes to it, overriding the
assumed "<[CON]>" option.
COPYING FILES USING RCP
Winsock RSHD/NT also provides Remote Copy (RCP) Server capability.
This allows you to copy files to and from a PC running Winsock
RSHD/NT using the rcp command.
The rcp command is commonly found on Unix systems, Windows NT
systems, and in some TCP/IP packages for Windows and DOS. If your
TCP/IP package does not provide the rcp command, you can use
Winsock RCP from Denicomp Systems.
The rcp command is described in more detail in your TCP/IP package
manual or with the manual that comes with Winsock RCP. However,
here are a few examples of its use.
Important Note: Unlike the standard Unix rcp command and Denicomp
Systems' rcp command (found in the Winsock RCP/RSH package), the
Windows NT rcp command copies all files with ASCII conversion by
default. Binary files must be copied using the -b option of NT's
rcp command. If you do not use the -b option on binary files, the
contents of the file will be altered on the destination system.
To copy a file from the host named "srvpc" to your PC or Unix
system, use:
rcp srvpc:yourfile myfile
The file "yourfile" is copied from the host named "srvpc" to the
file on your PC named "myfile". The host "srvpc" could be running
either Windows and Winsock RSHD/NT or Unix.
To copy a file from your PC or Unix system to the PC named
"srvpc", use:
rcp \lists\xmas.doc srvpc:\word\lists
The file \lists\xmas.doc is copied from your system to the file
xmas.doc in the directory \word\lists on the PC named "srvpc".
To send the entire directory tree from your PC or Unix system to
"srvpc", use:
rcp -b -r \share srvpc:\
All of the files and subdirectories in the directory \share are
copied to the PC named "srvpc". It will create a \share directory
in the root directory (\) of srvpc.
If the \share directory contained any subdirectories, they would
be created on the other PC and all the files in them would also be
copied.
To copy all of the files ending with ".xls" from "srvpc" to your
PC, use:
rcp -b srvpc:\sheets\*.xls .
This copies all of the files ending with ".xls" in the directory
\sheets on "srvpc" to the current directory (.) on your PC.
You can use drive letters if necessary. For example, to copy a
file from the A: drive on the "srvpc" to your PC:
rcp srvpc:a:file.txt file.txt
This will copy "file.txt" from the A: drive on "srvpc" to the file
"file.txt" on your system.
NOTE: Winsock RSHD/NT allows you to use both slashes (/) and
backslashes (\) for directory separators. It will adjust
appropriately. This is especially important for Unix users, since
backslashes are interpreted by the shell and must be escaped by
using two backslashes for every one backslash. Use slashes
instead.
SHUTTING DOWN AND REBOOTING WINDOWS NT USING RSH
Winsock RSHD/NT suppors two "internal" commands that allow you to remotely
shutdown or reboot the NT system. These commands do not actually exist
as programs - they are understood internally by RSHD/NT. To use them,
you need to use the special "<[INTERNAL]>" specifier. This can be
abbreviated to "<[INT]>".
The two internal commands are shutdown and reboot. The syntax is:
rsh ntsystem "<[INT]>" shutdown [#]
or
rsh ntsystem "<[INT]>" reboot [#]
Where # is an optional number of seconds to wait before the system shuts
down or reboots. If it is not specified, it is shutdown or rebooted
immediately.
For example:
rsh ntsystem "<[INT]>" shutdown 30
Waits 30 seconds and then shuts down the system. The command:
rsh ntsystem "<[INT]>" reboot
Immediately begins the reboot procedure.
WINSOCK RSHD/NT UTILITIES
Winsock RSHD/NT includes two utilities that allow you to control
the operation of the Winsock RSHD/NT service.
The first utility is wrshdctl. This can be run in two ways.
First, you can use the Service Control button in the Winsock
RSHD/NT Control Panel applet. Or, it can be found in the
directory in which you installed Winsock RSHD/NT. It is a Windows
NT program that allows you to install, start, stop, and remove the
Winsock RSHD/NT service.
To use it, get to a Windows NT Command Prompt (in the Main program
group). Change to the directory where Winsock RSHD/NT is
installed using the CD command (for example, CD \WRSHDNT). Then
type "wrshdctl".
You can run wrshdctl from the Windows NT Program Manager also, as
long as you are not going to use it to re-install Winsock RSHD/NT.
You must be in the Winsock RSHD/NT directory to re-install the
Winsock RSHD/NT Service if it has been removed.
You can then do the following:
Start the Winsock RSHD/NT Service
This starts the Winsock RSHD/NT Service if it is not currently running.
Stop the Winsock RSHD/NT Service
This stops the Winsock RSHD/NT Service if it is currently
running. This is useful when you have changed the Winsock
RSHD/NT configuration. Stopping and restarting Winsock
RSHD/NT will cause it to re-read the configuration options.
Install the Winsock RSHD/NT Service
This installs the Winsock RSHD/NT Service in Windows NT's
list of services. It does not install the files from the
Winsock RSHD/NT diskette. It only adds Winsock RSHD/NT to
the list of services that Windows NT can execute.
Remove the Winsock RSHD/NT Service
This removes the Winsock RSHD/NT Service from Windows NT's
list of services. It does not delete any files. It only
removes it from the list of services. Use the Install option
to add it to the list again.
There is another utility included with Winsock RSHD/NT that
performs the same operations as wrshdctl, but is a command line
oriented utility. It is called ctrlrshd.
This command can be executed from the Windows NT Command Prompt
while you are in the Winsock RSHD/NT directory (\WRSHDNT), unless
you have included that directory in your path. Its syntax is:
ctrlrshd install [auto | manual [directory]]
ctrlrshd start
ctrlrshd stop
ctrlrshd remove
The install option installs the Winsock RSHD/NT service in Windows
NT's list of services. It does not start Winsock RSHD/NT. You
can optionally specify whether you want Winsock RSHD/NT to start
automatically each time Windows NT is booted (auto) or if you want
to start Winsock RSHD/NT manually when necessary (manual). If you
do not specify either, auto is assumed. The directory option is
used when you are using the install option and Winsock RSHD/NT is
not installed in the current working directory. If it is not,
specify the directory name as the third parameter. Note that if
you specify a directory, then you must also specify auto or
manual.
The start option starts the Winsock RSHD/NT service. Winsock
RSHD/NT will begin accepting requests.
The stop option stops the Winsock RSHD/NT service. It will no
longer accept requests. This does not remove it from Windows NT's
list of services; it only stops it until you decide to restart it
using the start option.
The remove option removes Winsock RSHD/NT from Windows NT's list
of services. It will no longer accept requests and will no longer
be available to start or stop. Note that you must first use the
stop option if Winsock RSHD/NT is running before removing it.
The remove option does not delete any files; it only removes
Winsock RSHD/NT from the list of available services. You can
later add it back to the list using the install option.
FREQUENTLY ASKED QUESTIONS
Why does it sometimes take a few seconds for RSHD/NT to execute a
command from an rsh or to copy a file from an rcp command?
This is due to something in the Windows NT TCP/IP implementation.
Often, your first rcp or rsh will be fast, then subsequent
commands will be delayed by a few seconds. This delay is not
caused by RSHD/NT. It takes NT a few seconds at times to notify
RSHD/NT that there is a connection waiting. RSHD/NT processes the
request very quickly once it is notified.
To illustrate this, restart your NT system, then issue an rsh or
rcp command from another system to the NT system. It will be
quick. Then immediately issue another rcp or rsh; it will be
delayed by a few seconds.
The root of this problem can be explained somewhat, although
technical. After issue the first rcp or rsh, the TCP/IP
connection (a "socket") is closed and it goes into the TIME_WAIT
state, which is normal. You can see this by typing the netstat
command on the NT system after you do an rcp or rsh to it.
As long as there are closed sockets in the TIME_WAIT state which
were created by RSHD/NT, you will experience the delay. It takes
up to four minutes (a TCP/IP constant) for them to go out of the
TIME_WAIT state. Once they do, the next rcp or rsh will be quick.
Then the cycle repeats; you need to wait another four minutes for
it to be quick again.
We are not sure why this occurs. There is no way for the
TIME_WAIT state to be avoided with rcp and rsh; in fact, the
TCP/IP standards require that connections go into the TIME_WAIT
state after they are closed. The problem is not specific to
RSHD/NT, so we hope that at some time Microsoft will change this
behavior.
SUPPORT
Support is available via U.S. Mail and Compuserve/Internet.
Denicomp Systems
P.O. Box 731
Exton, PA 19341
Compuserve: 71612,2333
Internet: 71612.2333@compuserve.com